кода. В рамках ревью проверяется: соответствие архитектурному видению внесенных изменений в коде, необходимость изменить архитектуру, оправданность этих действий.
Важно поддерживать документацию архитектуры и актуализировать ее при внесении изменений. Задокументированная архитектура в актуальном состоянии — маяк в море вариаций решений по каждой конкретной задаче. Вы дадите разработчикам возможность не тратить время на ненужные правки, а новым членам команды проще понять принципы, по которым необходимо вносить изменения в продукт.
Аудит архитектуры необходимо проводить в случае, если нет жесткого контроля всех вносимых изменений в продукт. Таким образом в продукте:
— могут появиться изменения, нарушающие его архитектурную целостность
— документация могла потерять актуальность, и ее необходимо привести в соответствие с новой версией архитектуры.
Технический долг — это несделанная в проекте работа, которая если так и не будет выполнена, будет мешать развитию в будущем. В технический долг не включаются баги или отложенные низкоприоритетные фичи. Технический долг — это, например, плохо спроектированная архитектура или запутанный код.
Управление техническим долгом — это его постоянный поиск, подсчёт стоимости и постепенное устранение.
Что будет если не выплачивать технический долг?
— Будет расти время разработки и стоимость поддержки системы.
— Усложняется анализ кода, требуется много времени, чтобы разобраться в нём.
— Тяжелее вносить изменения — системы с техническим долгом отличаются хрупкостью.
— В какой-то момент станет невозможной дальнейшая поддержка системы.
— Её придётся выводить из использования или переписывать с нуля.
Почему копится технический долг?
— Программист делает ошибки при разработке проекта, которые не отлавливаются на code review или статическом анализе;
— Когда ситуация вынуждает писать код быстро и некачественно, к нему в будущем не возвращаются для рефакторинга;
— Объем технического долга не известен руководству;
— В команде не выделяется время на периодическое исправление технического долга;
— Разработчики игнорируют мелкие дефекты качества и не пытаются их исправить на месте по правилу бойскаута.
Как выявить технический долг?
— Контроль качества внешним аудитом
— Code Review
— Автоматизация оценки качества кода
Поддерживаемость и отказоустойчивость
Документация — инструмент улучшения поддерживаемости продукта за счет сохранения знаний о продукте, его строении и процессе разработки. Правильно организованная передача знаний позволит уменьшить риски при низком bus факторе. Стоимость создания и поддержки документации достаточно высокая, поэтому начинать работать с ней нужно с ответа на вопросы:
— Кто потребитель документации?
— Какой информации будет достаточно (наиболее важная)?
— Какой вид документа будет максимально удобным для потребителя?
Необходимо понимать, что, если не актуализировать документацию, она обесценится. То есть все вложенные инвестиции в ее создание ставятся под сомнение. Потребитель не знает в каком месте документация неактуальна, а следовательно, не может доверять ни одной строке.
Распределение ответственности за код ведет к снижению поддерживаемости кода. Для больших продуктов вам придется искать компромисс между разделением области кода среди разработчиков и фокусировкой их деятельности в отдельной области.
Прозрачность и гибкость архитектурного решения улучшает поддерживаемость за счет использования известных подходов, фреймворков и паттернов проектирования. Гибкость архитектурного решения создаст возможность дешево и быстро вносить изменения.
Однако часто гибкость увеличивает стоимость, такие решения должны быть экономически оправданны.
Хорошей практикой является измерение уровня сложности кода и «запаха» кода статическими анализаторами.
Отказоустойчивость решения достигается за счет:
— Проверки выпускаемых версий (unit тестами, приемочными и интеграционными тестами, пентестами и статическим анализом кода на безопасность)
— Построение отказоустойчивой схемы инфраструктуры
— Уменьшение человеческого фактора в процессе публикации релизов
Обеспечение высокой доступности также включает:
— Резервное копирование
— План восстановления (максимально автоматизированный)
— Дублирование компонентов, масштабируемую архитектуру и кэширование
— Защита от вторжений (brute force, XSS, ransomware, SQL injection, DDoS и др.)
— Дотирование
— Метрики и алерты
Управление производительностью начинается с прогнозов бизнеса о нагрузке на систему. Эти прогнозы строятся на своих показателях и не всегда легко превращаются в параметры системы. Вдобавок бизнес может иметь проблемы с долгосрочным планированием, необходимо учитывать неточность оценок и вероятность умышленной манипуляции прогнозом. Планирование должно быть регулярным и обеспечивать процесс разработки преждевременной информацией о необходимых изменениях.
На основании прогнозов бизнеса планируются задачи по обеспечению производительности. Повышение производительности достигается за счет применения теории ограничений. Тестирование таких задач должно подтверждаться успешным нагрузочным тестом. При этом хорошим тоном считается способность системы выдержать х2-х5 нагрузки от плановых значений.
Необходимо встроить процесс обеспечения производительности в процесс разработки таким образом, чтобы изменения не приводили к деградации производительности продукта. Для этого на ревью оценивается производительность тех или иных алгоритмов, а тестировщик проверяет новую пропускную способность измененного участка.
Есть ситуации, когда построить план по нагрузке физически невозможно, при этом нагрузка может скакать в диапазоне х10. В этих ситуациях бизнесу придется прибегнуть к дополнительным расходам, чтобы обеспечить доступность системы с использованием serverless архитектуры.
Необходимо организовать процесс управления инцидентами нехватки производительности. Структурированность в этом вопросе должна обеспечить минимальные потери и минимальный простой продукта, важно иметь рекомендации к быстрому реагированию на чрезмерную нагрузку. В рамках процесса выявляются первопричины и ставятся задачи по разрешению системных проблем.
Основные принципы проектирования и реализации безопасных систем:
— Конфиденциальность — свойство информации быть недоступной или закрытой для неавторизованных лиц, сущностей или процессов.
— Целостность — свойство сохранения правильности и полноты активов.
— Доступность — свойство информации быть доступной и готовой к использованию по запросу авторизованного субъекта, имеющего на это право.
— Невозможность отказа — подтверждение целостности и оригинального происхождения данных, которые исключают возможность подделки. Вся информация в любой момент может провериться сторонними лицами или пройти процесс установление идентичности (личности, документа, объекта). После данные с высокой степенью достоверности могут считаться подлинными без возможности опровержения.
Требования безопасности необходимо выявить до начала работы над продуктом.
Основные шаги выстраивания безопасности:
— Сбор и выявление всех требований к безопасности (фактически реализации шагов ниже)
— Требования к технологиям передачи, обработки и хранения информации
— Выявление видов информации
— Выявление ролей пользователей (для приложения и инфраструктуры)
— Определение прав для каждой роли (операции чтения, удаления, обработки и изменения каждого типа информации)
— Определение способа идентификации пользователя (в том числе в момент перебора паролей и DDoS-атак)
— Правила согласования выдачи доступов и процесс выдачи доступов
— Политика паролей
— Регламенты информационной безопасности (профилактика, инциденты безопасности)
— Журналирование важных для безопасности событий
— Управление рисками безопасности (оценка угроз)
— Использование средств активной защиты от атак
Более того, требования могут быть наложены на сам процесс разработки: внесение изменений в код продукта, публикация новой версии продукта, использование последних версий библиотек и поддерживающих приложений.
В подавляющем большинстве риски безопасности недооцениваются предприятиями, что возлагает на тимлида дополнительную ответственность за внимательное отношение к этому фактору. Для того чтобы переложить ответственность на
